IMPROVED CASH MANAGEMENT SERVICE PLATFORM

专利摘要:
The present invention relates to a computer system that performs a method for generating an action proposal design, said method comprising the steps of: (a) receiving required data from a business user by said server, said requirement data comprising a plurality of include bank transaction capacity requirements with regard to cash management and cash; (b) processing said required data by said server to generate an actual / intended analysis design available for a moderator user, said processing being based at least in part on said historical bank transaction data; (c) receiving a change of said requirement data from said moderator user and / or said business user, yielding changed requirement data; (d) processing said modified requirement data by said request generation server comprising an RFP (Request For Proposal) and a recipient list, said processing being based at least in part on said historical bank transaction data; (e) upon confirmation by at least said moderator user, sending said RFP to a plurality of bank users named in said recipient list; (f) receiving response data from said server from one or more bank users belonging to said plurality of bank users, said response data comprising a capacity selection for bank transactions and a plurality of bank transaction prices with respect to said plurality of capacity requirements for bank transactions; (g) processing said required data by said server to generate an analysis design available to a moderator user, said promotional proposal design comprising one or more of said plurality of bank transaction prices with respect to said plurality of bank transaction capacity requirements .
公开号:BE1025733B1
申请号:E2017/5974
申请日:2017-12-21
公开日:2019-06-24
发明作者:Didier Vandenhaute
申请人:Pwc Enterprise Advisory Cvba；
IPC主号:

专利说明:

IMPROVED CASH MANAGEMENT SERVICE PLATFORM
Technical area
The invention relates to the technical field of cash management for companies. This description relates in particular to the collection and analysis of data for the purpose of advising companies and banks on their cash management and cash.
Background
In the past, business interactions with banks tended to follow a non-centralized and non-optimized model of complicated bank flows between companies (and their branches) and their financial institutions (e.g., their banks). In this model, each company (or branch) and each bank communicated in its own way, often using proprietary communication channels. The complexity and ineffectiveness of this model was exacerbated by the significant number of companies and branches, and the significant number of financial institutions with which the companies and branches communicated.
More recently, there has been a transition to centralized payment flows and cash management. US 8,190,504 describes an optimization service platform of corporate payments, cash and cash management that helps to meet the need in corporate banking to get more value from the banking relationship with the company. The platform is integrated into the supply chain processes of the business customer and can provide predictive and optimizing liquidity services. The platform offers a one-to-many model in which the bank serves many companies with one system to save operating costs and strengthen economies of scale. In addition, it brings existing banking services to a higher level, while at the same time offering modular, configurable services in a secure, integrated solution. However, US 8,190,504 has no mechanism to track the historical data of bank transactions, and related thereto, has no way to update the capacities and prices of bank transactions with respect to said historical data. Moreover, US 8,190,504 does not provide mechanisms for comparing bank transaction prices with quantities calculated on the basis of historical data.
There remains a need in the state of the art for an improved cash management system. The present invention has for its object to solve at least some of the above problems.
BE2017 / 5974 Summary of the invention
The present invention relates to a service platform and related computer system for cash management. A moderator user acts as an intermediary between a business user and one or more bank users, whereby the business user is assisted by the moderator user in improving the bank structure of the business user. The moderator user, the business user and the one or more bank users each have access to the said service platform and related computer system through separate accounts. It is assumed here that sufficient authentication security and encryption is present to ensure that none of the users have access to account information that belongs to the accounts of other users. The general purpose of the aforementioned cash management is to improve the bank structure of the aforementioned business user. This involves rationalization, for example, by reducing the total number of banks used by the business user for cash management when doing business. Reviewing bank relationships allows significant savings for business users. In this revision process, the main concerns for business users are the creation of long-term partnerships with banks ("relationship" banks), maintaining sufficient banking diversity to manage counterparty risk and ensuring adequate credit resources as well as local support for cash management .
The present invention is therefore directed to a first objective, with regard to generating action proposal designs. The intended recipient of the aforementioned finalized action proposal is the business user. This first purpose relates to the revision of bank relationships, which is decided by the aforementioned business user based on a finalized action proposal supplied by the moderator user. The aforementioned finalized promotional proposal is based at least in part on an promotional proposal design generated in accordance with the present invention. In realizing the first object, the present invention makes it easier for all users involved, and in particular for the business user and / or the moderator user.
Furthermore, the invention is directed to a related second goal, with regard to the generation of bank benchmark report designs. The intended recipient of the aforementioned finalized bank benchmarking report is the benchmarking bank user, i.e. a bank user involved in said benchmarking. This second purpose relates to the revision of transaction bank capacities of one or
BE2017 / 5974 multiple banks that are associated with a benchmarking bank user, consisting of a benchmarking of the said one or more banks relative to the market. Said transaction bank capability revision is described in detail in a finalized bank benchmarking report, which is based at least in part on a bank benchmarking report design generated in accordance with the present invention. Also in realizing the second goal, the present invention makes it easier for all users involved, and in particular the benchmarking bank users and / or the moderator user.
First goal
In a first aspect with respect to the first object, the present invention provides a computer system for cash management, wherein the computer system comprises
- a server, the server comprising a processor, a tactile non-volatile memory, program code present on said memory for giving instructions to said processor;
- a computer-readable medium, wherein the computer-readable medium comprises a database, said database comprising historical data of bank transactions;
wherein said computer system is configured to perform a method for generating an action proposal design, said method comprising the following steps:
(a) receiving required data from a business user by said server, said requirement data comprising a plurality of capacity requirements for bank transactions with regard to cash management and cash;
(b) processing said required data by said server to generate an actual / desired analysis design that is available to a moderator user, said processing being based at least in part on said historical bank transaction data;
(c) receiving a change of said requirement data from said moderator user and / or said business user, yielding changed requirement data;
BE2017 / 5974 (d) the processing of said modified requirement data by said server for generating request data comprising an RFP (Request For Proposal) and a recipient list, said processing being based at least in part on said historical data on bank transactions;
(e) upon confirmation by at least said moderator user, sending said RFP to a plurality of bank users named in said recipient list;
(f) receiving response data from said server from one or more bank users belonging to said plurality of bank users, said response data comprising a capacity selection for bank transactions and a plurality of bank transaction prices with respect to said plurality of capacity requirements for bank transactions;
(g) processing said response data by said server to generate said promotional proposal design available to said moderator user, said promotional proposal design comprising one or more of said plurality of bank transaction prices with respect to said plurality of capacity requirements on bank transactions;
characterized in that said receiving in step (f) comprises at least partially automated updating of said historical bank transaction data based on said response data, and said processing in step (g) comprises comparing a bank transaction price that belongs up to said plurality of bank transaction prices with an amount calculated on the basis of or available in said historical bank transaction data.
In a preferred embodiment, said computer system further comprises a corporate user interface and an IDAM server different from said server; said business user interface comprising a representation layer configured for HTTPS-based interaction with a user-related business user device; wherein said computer system comprises a web API configured for interaction between said representation layer and a processing part of said computer system; wherein said web API is configured for validation
BE2017 / 5974 of a token generated by said IDAM server; wherein said receiving in step (a) relates to the use of said corporate user interface; and wherein said representation layer is configured to perform the following sub-steps that belong to step (a) and which are related to authentication of said user against said computer system:
(a.i) receiving credentials, preferably a user name and password, from said business user via said HTTPS-based interaction with said user-related device; (a.ii) requesting said token from said IDAM server based on said credentials; (a.iii) receiving said token from said IDAM server and storing said token; (a.iv) providing said user with access to the computer system; (a.v) receiving a portion of said required data from said business user via said HTTPS-based interaction; (a.vi) sending a message comprising said portion of said required data received in the step and said token stored in the step to said web API; (a.vii) after optional validation of said token, receiving a response from said web API to said portion of said required data; (a.viii) giving said user said response to said portion of said required data.
Such an embodiment has the advantage that it provides an additional security layer, which is moreover integrated with the security already provided by the use of HTTPS. In a further preferred embodiment, the said web API relates to a REST API; said representation layer relates to HTML 5; and the said token relates to a JSON web token.
In a preferred embodiment, said comparison of said transaction price with said amount comprises comparing the
BE2017 / 5974 said transaction price with any or some of the following: transaction prices that are different from said transaction price, but that are also provided in the context of said promotional proposal design; recent prices of the business user given in the context of a second promotional proposal design that is different from the aforementioned promotional proposal design; recent prizes given by one or more bank users in the context of a third promotional proposal design that is different from the aforementioned promotional proposal design. Here, the information required in the comparison is, if necessary, retrieved from the database including the historical data on bank transactions.
The computer system and the related use according to the present invention offers several advantages. In general, the mentioned system ensures increased efficiency. The system offers a one-to-many model in which the operator user cooperates with many business users and bank users with one system to save operating costs and strengthen economies of scale. Moreover, the system offers a modular approach at the level of individual bank transaction capacities. In addition, the system allows an integrated and secure approach to cash management. A specific example with respect to such a system is given below in Example 1 with reference to Figure 1.
By standardizing the processes of receiving required data in step (a), repeating the business user by means of an actual / desired analysis in step (b) and (c), sending an RFP to banks in step ( e) and receiving response data in step (f), fewer resources are used to achieve the intended goal of cash management and to prepare an action proposal. What is important is that this standardization allows better facilitation by the system that historical data on banking transactions is kept in a separate database that is preferably updated in real time as different business users and bank users are served by it. The prices of step (f) are particularly relevant for future use. Consequently, the actions of the business users and bank users result in real-time database updates that are preferably only visible to the moderator user for confidentiality reasons. This is particularly advantageous in cases where value moderator user represents a large company cooperating with a large number of business users and bank users at the same time, value update of a quantity in the database with regard to the specific capacity of bank transactions with regard to a first business user may result in the better processing of a request from a second business user that is different from the first business user
BE2017 / 5974 is involved in the same specific capacity for bank transactions. To achieve the same objective, cash management and drafting of action proposals with prior art systems would either result in a huge logistical problem or lead to a low quality of the result compared to the result possible with a system according to the present invention. .
Another advantage of the present system is the ability to compare bank transaction prices with quantities calculated on the basis of historical data collected in the context of previous promotional proposal designs. Since bank transaction prices play an important role in the preparation of the action proposal, such a comparison allows for important controls of the evolution of the prices mentioned over the years. Related to this, the comparison can also make it possible to assess whether a certain price is too high in the light of historical data.
Moreover, specific advantages for different users of the system according to the present invention can be identified. For a business user, the said system allows faster service, reducing the time required between providing required data and possibly receiving a finalized action proposal from the moderator user. For a moderator user, the said system allows a bundled approach for collaboration with a variety of business users and bank users. It is important that the moderator user is further provided with a knowledge database. For a bank user, said system streamlines the process of responding separately to a variety of RFPs, leading to a general reduction in effort made in the process. This leads to a higher efficiency per RFP for the relevant bank user. In addition, the bank user can take advantage of the system in the role of benchmarking bank user, in a method related to the aforementioned second goal, as discussed in detail below.
In a preferred embodiment, the computer system according to the present invention comprises a business user interface suitable for display to the business user. Herein, said receiving in step (a) relates to the use of said business user interface, wherein said business user interface comprises a questionnaire suitable for successive completion by said business user, said questionnaire comprising a plurality of questions regarding cash management and cash, the said questionnaire being at least one
BE2017 / 5974 includes interdependence between a first and second question that belongs to the said plurality of questions.
For the business user, the advantage of an embodiment with such a questionnaire is that it provides a standardized and reliable means for communicating requirements to the moderator user. Because the interface is provided by the system, a more uniform approach can be realized over different requests from the same business user. In addition, the fact that the interface and the questionnaire are provided by the system increases reliability, since all previous answers from the business user can also be stored on the server, either as a backup or as a service for the business user. Moreover, the interdependence between questions from the questionnaire allows easier communication with the business user. In a preferred embodiment, such interdependence includes automatically hiding a particular question if the answer to a question preceding the particular question indicates that the particular question is superfluous and should not be asked. In this way, the questionnaire can be automatically adapted to the needs of the business user, resulting in a better user experience and related faster completion of the questionnaire.
In a further preferred embodiment, the said plurality of questions belonging to the questionnaire relates to any or any combination of the following: an estimated annual turnover, estimated annual total bank costs, a detailed unit cost, a country-specific overview of transaction types. Here, a transaction type is preferably linked to a specific country. This is advantageous since it allows for taking into account the specific requirements with regard to each country individually, as required by the general scope of cash management and cash.
In a further preferred embodiment of the system, with respect to said successive completion of said questionnaire by said business user, a sum of two or more amounts is given by said business user in response to said plurality of questions compared to a plurality of questions estimate also provided by said business user in response to said plurality of questions, said estimate referring to said sum of two or more quantities. This is advantageous since it provides a means for identifying problems with the required data as given by the business user in one
BE2017 / 5974 early phase. In another related preferred embodiment, this is combined with a warning, wherein said business user interface is configured to generate a warning for said business user when said sum of two or more amounts falls outside a range defined by said estimate and a predefined tolerance level. An important advantage of such a system is the immediate feedback received by the business user, without the intervention of the moderato user being necessary, which results in a faster and more efficient overall completion of the questionnaire. Examples of such warnings include cases where a sum of quantities is much greater or lower than an expected value such as the estimated annual sales or estimated annual total bank charges, which may indicate that business user correction is required.
In a further preferred embodiment of the present invention, said computer system comprises a bank user interface suitable for display to the business user, wherein said receiving in step (f) relates to the use of said bank user interface, said bank user interface being a display of a plurality of requests comprises at least in part based on said RFP, said representation of said plurality of requests being suitable for successive completion by said bank user. An advantage of such a bank user interface with display is that it provides bank users with a standardized way of communicating an answer to an RFP, allowing them to be handled more efficiently since more answers are requested via the same system according to the present invention.
In another preferred embodiment, said computer system comprises a user account comprising contact details for at least one of the bank user, the moderator user and the business user; and said computer system is further configured to send a notification to said bank user and / or said moderator user and / or said business user via said contact details, said notification being triggered by an agenda item and / or deadline with with respect to said method for generating said promotional proposal design. This notification can take the form of a message on a screen, SMS (short message service), chat message and / or push notification. This has the advantage that a problem with a bank transaction price can be identified in
BE2017 / 5974 is an early phase and can be reported to the user for whom the said report is suitable, permissible and relevant.
Second goal
According to another embodiment with respect to said second target, said computer system is further configured to perform a method for generating a bank benchmark report design, said method comprising the following steps:
(i) retrieving benchmarking information relating to a benchmarking bank user by said server;
(ii) processing said benchmarking information to generate said bank benchmarking report design, said processing being based at least in part on said historical bank transaction data;
wherein said benchmarking information is retrieved in step (i) by any or only combination of: querying said benchmarking bank user; requesting the aforementioned historical data on bank transactions. Such a system makes it possible to get more out of the data present in the database, also for the benchmarking of banks, in the form of a service provided by the moderator user to the benchmarking bank user. For the sake of confidentiality, it is important that the information provided to the benchmarking bank user does not provide details regarding banks. A specific example with respect to such a system is given below in Example 2 with reference to Figure 2.
In a preferred embodiment, the system of the present invention is adapted to perform both steps (a) to (g) and steps (i) to (ii) with respect to the first and second targets, respectively. This embodiment is preferred since the two objectives are related and their joint realization leads to a more effective implementation compared to systems where both objectives are addressed separately. In an alternative embodiment, said system is adapted to perform only steps (a) to (g). In yet another embodiment, said system is adapted to perform only steps (i) to (ii).
BE2017 / 5974 Use related to the second goal
In a second aspect, the present invention relates to the use of a cash management computer system according to the present invention for generating a benchmarking bank report design, with respect to said second purpose. This is particularly advantageous in an embodiment where the computer system is configured to perform both steps (a) to (g) and steps (i) and (ii). Namely, in generating action proposal designs with respect to the first goal, the system accumulates a variety of useful data including said historical bank transaction data. The presence of this useful data is advantageous in generating a benchmarking bank report design, since it generally permits better results than would be achieved by a prior art system that generates benchmarking bank report designs without access to data accumulated during the generation of promotional proposal designs.
Further aspects of the invention will be discussed in the detailed description of the invention and in the dependent claims.
DESCRIPTION OF THE FIGURES
Figure 1 is an overview diagram illustrating a method for generating an action proposal design according to the present invention.
Figure 2 is an overview diagram illustrating a method for generating a bank benchmark report design according to the present invention.
Figure 3 shows an example of a first instance of a project list screen of a web application according to the present invention.
Figure 4 shows an example of a second instance of a project list screen of a web application according to the present invention.
Figure 5 shows an example of a first instance of a dashboard screen of a web application according to the present invention.
Figure 6 shows an example of a screen for creating a questionnaire of a web application according to the present invention.
Figure 7 shows an example of a second instance of a dashboard screen of a web application according to the present invention.
BE2017 / 5974 Figure 8 shows an example of a third instance of a dashboard screen of a web application according to the present invention.
Figure 9 shows an example of a screen for editing a project of a web application according to the present invention.
Figure 10 shows a preferred authentication mechanism according to the present invention.
Detailed description of the invention
As stated in the summary of the invention, an aspect with respect to the said first object of the present invention is the generation of an action proposal design. The promotional proposal design serves as a basis for the finalized promotional proposal, which is based at least in part on the promotional proposal design. The action proposal design is a document generated as output by the computer system according to steps (a) and (g) of the present invention. The intended recipient is the business recipient. The promotional proposal design can be used by the moderator user to generate a finalized promotional proposal. The promotional proposal design relates in particular to a preliminary document that can lead to the finalized promotional proposal, but usually requires some manual intervention from the moderator user. In the manual intervention, the moderator user uses her / his experience and knowledge of cash management and cash resources to adjust the content and structure of the action proposal design. In particular, those parts of the promotional proposal design that are less easy to automate, such as strategic decision making parts, require specific attention from the moderator user when modifying the promotional proposal design. The result of the manual intervention is the finalized action proposal. This finalized action proposal is the document that is delivered to the business user by the moderator user. In a preferred embodiment of the present invention, the finalized action proposal is delivered to the business user via said computer system in a separate step that takes place after step (g). In an alternative embodiment, the role of the computer system according to the present invention ends upon delivery of the promotional proposal design, and the computer system is not involved in the delivery of the finalized promotional proposal to the business user.
In this document, the finalized action proposal refers to a proposal by the moderator user to the business user regarding the revision of
BE2017 / 5974 banking relationships. The finalized action proposal includes, among other things, a list of possible actions for revising bank relationships. It also includes bank transaction prices. In a preferred embodiment, the promotional proposal further comprises an analysis of the transaction prices, comparing bank transaction costs as given by the business user with bank responses to the RFP. In a further preferred embodiment, the said promotional proposal further comprises a cash centralization analysis.
Another aspect of the invention with respect to said second purpose is the generation of a bank benchmark report design. This bank benchmark report design is prepared in steps (i) and (ii) according to the present invention, and serves as a basis for the finalized bank benchmark report, which is based at least in part on the bank benchmark report design. The intended recipient is the benchmarking bank user. The relationship between the bank benchmarking report design and the finalized bank benchmarking report is therefore similar to that between the promotional proposal design and the finalized promotional proposal, yet the intended recipient is different. The bank benchmark report design refers to a preliminary document that can lead to the finalized bank benchmark report, but usually requires some manual intervention from the moderator user. The manual intervention is needed to allow the moderator user to apply her / his skill and knowledge regarding cash management and cash. The manual intervention includes changes to the content and structure of the bank benchmark report design. The changes are mainly aimed at those parts that cannot be automated or are less easily automated, such as parts related to strategic decision making, which require specific attention from the moderator user. The result of the manual intervention is the finalized bank benchmarking report. This finalized bank benchmarking report is the document that is delivered to the benchmarking bank user by the moderator user. In a preferred embodiment of the present invention, the finalized bank benchmarking report is delivered to the benchmarking bank user via said computer system in a separate step that occurs after step (ii). In an alternative embodiment, the role of the computer system according to the present invention ends upon delivery of the promotional proposal design, and the computer system is not involved in the delivery of the finalized promotional proposal to the benchmarking bank user.
BE2017 / 5974 In this document, the finalized benchmarking report refers to a proposal by the moderator user to the benchmarking bank user regarding the revision of bank transaction capabilities of one or more banks associated with the said benchmarking bank user. The finalized action proposal consists of benchmarking the aforementioned one or more banks against the market. Hereby the anonymity of data with regard to banks other than the one or more banks mentioned is assured by proper processing of the said data.
The terms cash management and bank transaction capacities as used in this document are umbrella terms that refer to the effective planning, monitoring and management of cash / near cash. They can include at least one of the following:
- Daily cash check and forecast;
- Bank account structure and interest conditions;
- Receipts / collections;
- Payments;
- Investments and loans in the short term;
- Hedging activities (exchange rate, commodities, etc.);
- Management of bank relationships;
- Cash management (cash pooling);
- Trade financing and credit lines;
- Cash management systems (with interfaces with Enterprise Resource Planning systems).
In this document, the term quantity refers to a quantity received directly or indirectly based on historical data from bank transactions. Said amount is used as a reference in the evaluation of a bank transaction price, said bank transaction price being compared with said amount. The term predefined fraction, related to this, indicates in this document an allowable surplus of said bank transaction price with respect to said amount, the allowable surplus being determined in advance. In a preferred embodiment, the predefined fraction is used to specify a limit, wherein said fraction is a relative measure expressed as a percentage, e.g. 20%, and wherein said surplus is permissible if the bank transaction price does not exceed 20 % is higher than the stated amount. In
BE2017 / 5974 In a preferred embodiment, the bank transaction price that is not admissible is labeled as an offshoot.
In this document, the term predefined tolerance level refers to required data received from the business user and indicates an allowable deviation of a sum of two or more quantities from a reference value, the allowable deviation being determined in advance. In a preferred embodiment, the tolerance level is used to specify a range, wherein said tolerance level is a relative measure expressed as a percentage, e.g., 20%, and wherein said deviation is permissible as said sum of two or more amounts. does not deviate more than, for example, 20% from the reference value, nor is it 20% smaller nor 20% larger than the stated reference value. In a preferred embodiment, said reference value is an amount given by the business user, such as an estimated annual turnover or estimated annual total bank charges.
In this document, web API refers to a web application programming interface, a set of functions and procedures that describe how to interface with an application. Furthermore, IDAM server refers to an identity and access control server. This involves creating, defining, and managing the use and protection of identity information, as well as managing the relationship between an entity such as a user profile and the resources to which access is required. The term REST refers to representational status transfer. The term JSON refers to the so-called RESTful applications, and refers to JavaScript Object Notation, a format used for the exchange of data structures. Here, a RESTful API, or REST API, is a method to allow communication between a web-based client and server that uses representational status transfer (REST) restrictions. A JSON web token, generally abbreviated as JWT, is a compact URL-safe means for presenting claims, preferably credentials for granting access, that must be transferred between two parties. The claims are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS).
In a further preferred embodiment of the system according to the present invention, said business user interface comprises a progress bar that indicates a progress of said business user in completing said questionnaire. This can be any graphic or character-based line or shape that is indicative of or relates to the
BE2017 / 5974 relative progress of the business user when completing the questionnaire. This enhances the user experience for a business user, increasing the motivation to complete the questionnaire since the amount of remaining work can be better estimated.
In a further preferred embodiment, said computer system comprises a means for assisting the moderator user in creating said questionnaire. This leads to a more efficient and more standardized result than with a prior art system. In addition, the questionnaires created within the system are fully compliant as standard, while questionnaires created within the system have to be imported outside the system, which causes an extra effort (and therefore extra costs), and related risk of compatibility problems with regard to importing questionnaires in different file formats.
In a further preferred embodiment of the system, said promotional proposal design comprises more than one alternative to the promotional proposal. Namely, since the system automatically collects bank transaction capabilities and bank transaction prices, in a preferred embodiment, this automation is used to generate a multitude of alternatives to the promotional proposal that belong to the same promotional proposal design, the system ensuring that all alternatives to the promotional proposal are both feasible and be profitable. This has the advantage that the moderator user is given a choice between different possible alternatives to the promotional proposal, and can choose, optionally after changes, to propose a selection of the generated alternatives to the promotional proposal in the finalized promotional proposal that is delivered to the business user.
The invention will be further described by the following non-limitative example, which further illustrates the invention, and is not intended, and should not be construed as limiting the scope of the invention.
Example 1: method for generating an action proposal design
In an exemplary embodiment, the computer system of the present invention is a service platform configured to perform the method 100 illustrated in Figure 1.
In this example, the method 100 is started when the business user enters into an agreement with the moderator user to restructure its banking landscape and reduce the bank charges. In the context of working method
BE2017 / 5974 100 it is the company, via its business user, that is the customer of the moderator, via its moderator user. The moderator user assists the business user in achieving the stated objectives according to the following steps:
(a) receiving 101 required data from a business user by said server, said required data comprising a plurality of capacity requirements for bank transactions with respect to cash management and cash, including information regarding current prices and structure;
(b) processing 102 of said required data by said server to generate an actual / desired analysis design that is available to a moderator user, said processing being based at least in part on said historical bank transaction data;
(c) receiving a change of said required data from said moderator user and / or said business user, yielding changed required data;
(d) processing 104 of said modified requirement data by said server for generating request data comprising an RFP (Request For Proposal) and a recipient list, said processing being based at least in part on said historical bank transaction data ;
(e) upon confirmation by at least said moderator user, sending
105 from said RFP to a plurality of bank users named in said recipient list;
(f) receiving 106 of response data by said server from one or more bank users belonging to said plurality of bank users, said response data comprising a capacity selection for bank transactions and a plurality of bank transaction prices with respect to said plurality of capacity requirements for bank transactions ;
(g) processing 107 of said response data by said server to generate said action proposal design available to said moderator user, said action proposal design comprising one or more of said plurality of
BE2017 / 5974 includes bank transaction prices with respect to said plurality of capacity requirements for bank transactions;
characterized in that said receiving in step (f) comprises at least partially automated updating of said historical bank transaction data based on said response data, and said processing in step (g) comprises comparing a bank transaction price that belongs up to said plurality of bank transaction prices with an amount calculated on the basis of or available in said historical bank transaction data.
First, a data collection phase is performed through a questionnaire in step (a) to identify the current structure and costs of the business user, in which an attempt is made to retrieve information regarding current prices and structure. Collected data is then first analyzed by the service platform, to generate an actual / intended analysis design, taking into account the historical data on bank transactions that are available in the service platform. This design is then analyzed by the moderator user; this is usually done at least in part without the help of the service platform. This analysis yields an actual / intended analysis document comprising an initial business case. The findings of the actual / intended analysis are presented to the business user by the moderator user in a design workshop, intended to share the main findings and make decisions regarding the intended structure. After this workshop, the decisions made by the moderator user and / or the business user are sent back to the service platform by the moderator user in the form of changes to the initial requirement, in step (c). In other words, the lessons learned from the workshop are submitted to the service platform in step (c). After sending back to the service platform, the changed requirement is used by the service platform to generate a Request for Proposal (RFP, quote) in step (d), which is sent to a selection of bank users in step (e) for selecting the bank partners for the future. The responses to the RFP received in step (f) are first processed by the service platform to generate an action proposal design. This is handed over to the moderator user who builds a financial business case together with a recommendation, where it is documented with a finalized action proposal that is handed over to the business user.
BE2017 / 5974 Example 2: method for generating a bank benchmark report design
In a spring image execution, the computer system according to the present invention is a service platform that is further configured to implement the method 200 illustrated in Figure 2. The method 200 is designed to generate a bank benchmark report design
In this example, the method 200 is started when the benchmarking bank user starts a project with the moderator user for benchmarking the bank's banking transaction services. Bank benchmarks can include different dimensions such as business offers, technology, geographic coverage, customer service and implementation management. The project can be based on a formal agreement such as a contract, but it can also be based on an informal agreement between the benchmarking bank user and the operator user. In any case, in the context of method 200, it is the bank, via its benchmarking bank user, who is the moderator's customer, via its moderator user. The moderator user assists the benchmarking bank user in achieving the stated objectives in steps (i) and (ii) below. Here, the moderator makes use of the acquired knowledge, for example, while serving business users according to method 100. This knowledge comprises details about the service offering and the capacities of the bank, both locally and globally. The method comprises the following steps:
(i) retrieving 201 benchmarking information relating to a benchmarking bank user by said server;
(ii) processing 202 of said benchmarking information to generate said bank benchmark report design, said processing being based at least in part on said historical bank transaction data;
wherein said benchmarking information is retrieved in step (i) by any or only combination of: querying said benchmarking bank user; requesting the aforementioned historical data on bank transactions.
The input for the bench benchmarking, coming from the benchmarking bank user, can come from 2 different sources or can be a mix of both:
- banks' responses to RFPs;
- banks that provide information directly for the purpose of the benchmark.
BE2017 / 5974
In the first case, the service platform automatically searches for information in step (i) regarding the most recent answers from that particular bank to the various questions / topics on which the bank wants to perform the bank benchmarking analysis. The service platform database is a reliable source as it is updated every time new responses to RFPs are submitted on the platform. In addition, new responses to RFPs usually come for historical responses to all non-price related data. However, the method preferably does not only take into account the responses of RFPs in final status. As the data is very confidential for banks, the service platform is designed to keep the data private and secure at all times. Data is thereby consolidated to ensure that the benchmarking bank user does not have access to confidential information from competing banks.
In the second case, the moderator user gives access to the questions / topics for which the benchmarking analysis is performed for a benchmarking bank user via a graphical interface. Benchmarking bank data only sees data that is related to their own bank and can change it or enter new data. All changes made by the benchmarking bank users themselves in step (i) are checked and validated by the moderator user. They are preferably not automatically updated by more recent RFPs without control by the moderator user.
The data collected in step (i) leads to the generation of a bank benchmark report design by the service platform in step (ii). This design is submitted by the moderator user for finalizing the document and obtaining a bank benchmarking report that is delivered to the bank user.
Data within the database with regard to method 200 are categorized and hierarchized as follows:
- category (i.e. connectivity);
- product (i.e., electronic banking system - EBS);
component (i.e. coverage);
- RFP related requirement (i.e., number of supported languages): any 'closed' RFP question that is an RFP related requirement.
For each RFP-related requirement in the database, the moderator user assesses its importance level (e.g., basis, added value, or best
BE2017 / 5974 in class). This must be able to be edited within the service platform by moderator users.
The output of a bank benchmarking project is the aforementioned bank benchmarking report. The report compares the bank's offer with that of the group of competitors / peers. This report contains data retrieved from the database in step (i) and / or step (ii), with the bank ranked by each RFP-related requirement compared to its peers. The latter ranking is also done with the help of consolidated data, which prevents benchmarking bank users from having access to confidential information from competing banks.
To configure the service platform when generating the report design, the moderator user can:
- select which banks should be included in the peer group;
- select which individual category / product / component / RFP-related requirement should be included in the benchmark;
- have access to the priority level of each RFP-related component that has not been met by the bank.
Accordingly, a bank benchmarking report provides a consolidated view of the capabilities of the bank's peer group. Under no circumstances can the bank identify the capabilities of individual competitors on the basis of the bank benchmarking report. The number of other banks involved in the benchmarking is usually at least three, and preferably five or more, to allow sufficient anonymity.
In addition, moderator users have the option to interact with the service platform also by querying the database, they can compile charts, maps and tables based on data retrieved in step (i), but also based on data present in the database and associated with method 100, e.g., country and bank data sheet data.
Example 3: promotion proposal design
The following is an exemplary structure of an action proposal design, as it is obtained at least in part based on the action proposal design as generated by the system of the present invention. The action proposal design can be part of a general recommendation from the moderator user to the business user regarding the intended one
BE2017 / 5974 bank structure, where the business user is assisted in selecting their future bank partner (s). The action proposal design includes an analysis of the savings with regard to:
• the transaction prices • the cash centralization • the new bank structure
The savings are calculated per bank, but also according to different alternatives with more than one bank selected for the reach of the countries. The analysis is performed at least in part by the system.
Transaction prices
The transaction price analysis compares bank transaction costs as obtained in step (a) with the bank's actual responses to the RFP in step (f). The analysis includes a list of payment instruments by country, currency and total costs, and for each bank that has responded to the RFP:
- Proposed unit cost
- Absolute and relative difference in unity
- Total cost
- Total saving
All costs are automatically converted to the reference currency required for the promotional proposal design. The total costs per country and per bank are shown separately.
Related to this, a summary chart is included that shows the current bank transaction costs per country / region / global versus the bank's new prices.
In addition, a scenario analysis of the bank's responses has been included. This relates to alternatives to the action proposal, which allow the moderator user to divide the business between different banks and to have an estimate of the total costs and savings. For example, it is possible to calculate the total cost when assigning the EMEA area to one bank, and APAC to another bank. Scenarios must be based on assigning either regions, countries or bank accounts to different banks.
BE2017 / 5974 Cash centralization
This analysis identifies how much cash can be centralized (per currency) and at what cost based on:
- the average cash balance per bank account, which is reported via the questionnaire
- the current capacities of the bank in terms of cash pooling, which is reported in response to the RFP
- the arrangement concerning structures for cash pooling per country
This calculation is performed per bank, but also via a scenario analysis, i.e. it indicates which country / region is assigned to which bank.
The output of this analysis includes one or more graphs, such as a graph that shows the impact of cash centralization on a map of the world (actual situation versus intended situation based on different scenarios).
Bank structure
The cost of the new bank structure comprises various elements:
- Maintenance costs of the bank account
- Cash pool costs
- Costs for bank communications (depending on the communication channel and the number of users)
- Reporting costs
All actual costs can be calculated based on the information in the initial questionnaire and its related sections, based on, for example, the following:
- Maintenance costs from a Bank accounts section
- Costs related to cash pooling from a Bank Accounts section
- Costs related to the electronic banking system (EBS) from the Channel and formats section
- Reporting costs from the Channel and formats section
To calculate the intended costs based on the proposed prices of each bank, a new structure must first be designed within the solution. This new structure must allow the user to specify the following:
- Number of accounts in each currency per entity and country
- Number of ESB users per entity and country (or other communication channels)
BE2017 / 5974
- Reporting needs for each account
- Cash pooling needs for each account or group of accounts within a country
The costs associated with the intended bank structure are calculated based on this structure. These costs are given both in a table and in a graph, showing the current costs (per category) and the costs based on bank responses on the RFP. The calculation of costs can vary from bank to bank, some charge ESB costs per user while others charge this per country.
Similar to the bank transaction costs, a scenario analysis has been included about the bank replies, by dividing the cases between different banks.
Business Case
The promotional proposal design also includes a business case. The aforementioned business case is based on the three previous items: bank transaction costs, cash centralization and bank structure. It summarizes the costs and savings of each item per bank and area / country, and for each selected scenario. It is shown by means of one or more graphs showing the current costs and each proposal of bank costs.
Example 4: example web interface
Figures 3 to 9 show examples of web interfaces of a road application illustrating various aspects of the present invention. The web application is primarily intended for the moderator user and the admin user, with full access, and also for the business user, with specific access to relevant modules, images and interfaces of the application. Here, the breathing user is preferably a moderator user with additional privileges and editing rights that are not available to all moderator users. The bank user also has limited access to the specified interfaces with regard to the response to the RFP. Figures 3 to 9 merely illustrate some of the screens that may be useful in implementing the present invention as a web application.
The web application is accessible via a general web browser with a title bar 310 comprising an address bar 311 into which a URL can be entered with a well-known format, e.g., http://adres.net. The transfer protocol in this example is https,
BE2017 / 5974 allowing secure access with encryption of data entered and received via the web interface.
In the embodiment illustrated in Figure 3-9, the URL does not change depending on the web application screen and / or the progress phase of the products being displayed. In an alternative embodiment, the URL may change depending on which screen of the web application has been requested and / or depending on which phase of a particular project has been reached.
The web application is only open to registered users. Authentication is based on credentials, where the credentials consist of the user name and a password. These credentials can be entered in a separate login screen (not shown).
For each of the instances / screens of Figure 3-9, the web application screen includes a header bar 320. The header bar 320 includes a home button 321 and a screen-related title zone 322 related to the title of the web application screen that is on that moment is displayed. Further, the header bar 320 includes a user name indication zone 323, which indicates the user name according to the credentials used for logging in, and a system settings zone 324, with a selectable icon for system settings.
Upon selection of the home button 321, the user is directed to the project list screen 300, 400 of the application. The project list screen 300, 400 is displayed after the user has successfully logged in. Figures 3 and 4 show a first instance 300 and a second instance 400 of the project list screen 300, 400 of the web application. The project list screen is provided with a project toolbar 410 which is displayed at the top of the screen and which is visible when the top of the list is displayed, as in Figure 4, and is not visible as the user scrolls down for other projects in the list, such as Figure 3. The features and appearance of the project toolbar 410 depend on the user profile, and therefore differ depending on the type of user profile. For example, an admin user may be the only type of user profile that can create a new project, which may correspond to the inclusion of a corresponding attribute in the project toolbar 410 (see also below).
The project toolbar 410 includes a project search window 411 that allows to perform a search based on, e.g., the project name or company name. The project toolbar 410 further includes a sort-related selection menu 412 that offers the options to sort the projects by creation date, next deadline, alphabetically
BE2017 / 5974 according to company name, alphabetically according to project name. As can be seen, projects, in the example of Figs. 3 and 4, are sorted according to creation date 345. For a particular class of users, preferably each admin user and / or moderator user, the project toolbar 410 also includes a project status selection menu 413 that is on the Allows user to filter projects according to their status, showing only projects whose status is either Ongoing, Closed or Canceled. Finally, the project toolbar includes a new project zone 414 with selectable + (plus) icon, which is preferably only visible to breath users. Upon selection, the user is directed to a screen for creating a project (not shown). On the screen for creating a project, the user can enter details regarding a new project; the screen for creating a project is similar to the screen for editing a project 900.
The project list screen 300, 400 shows different project items 331-335 in the project item zone 330. A total of ten items is indicated for each project item 331-335. In particular, each project item 331-335 includes the project name 341, the current project phase 342, an indication of the next deadline (if the case) 343, preferably equal to the date of the next project phase (if the case), the project status 344 , the creation date 345, the company name 346, an indication of main users if applicable / known 347, the location of the cash of the group 348, the location of the head office 349, and a dashboard-related zone 350 with a selectable dashboard-related icon. The main users can be related to moderator users who are assigned as contacts for the specific project. The current project phase 342 is shown in text along with an annular icon that illustrates the relative progress on a circular scale. Based on this ring-shaped pictogram, it is clear that project item 331, with current project phase 342 Bank selection, is in a further or later phase than project item 332, with current project phase 342 Collecting data. Finished projects are visually recognizable with a completed ring for the current project phase 342, leading to the absence of a subsequent deadline 343.
When the dashboard-related icon is selected in the dashboard-related zone 350, a dashboard screen 500, 700, 800 is displayed. Here, Figure 5 relates to a first instance 500 of the dashboard screen with respect to a first viewing date, while Figure 6 relates to a second instance 600 with a second and later viewing date, and Figure 8 relates to a third instance 800 with a third and even later viewing date. Figure 5 shows a first instance of Project A dashboard screen 500, as obtained by selecting
ΤΊ
172017/5974 the dashboard-related icon of the project item 332 as it is shown in Figure 3, where the current project phase is 342 Data collection.
The dashboard screen 500, 700, 800 includes a dashboard tab bar 510 with selectable first tab 511 Axis is analysis and selectable second tab 512 Bank selection. The dashboard screen still includes the header bar 320 and now, in the case of a moderator user, it further includes a selectable change button 326; upon selection, the user is directed to the editing screen of the project 900, the details of which are given below. The dashboard screen 500, 700, 800 further includes a project phase timeline 520, including multiple project phase dates 521-526. The project phase dates 521-526 are directly related to other parameters of the web application, such as the current project phase 342, as indicated in Figs. 3 and 4, and are preferably directly related thereto, and more preferably a direct function of the comparison of the current date (ie the date the user uses the application) with the project phase dates 521-526.
The project phases 342 and project phase dates 521-526 are defined by project modifications. Not all dates must be set, and are therefore all optional. In the present example, the first, second, and sixth project phase dates 521, 522, 526 are considered to be defined when the dashboard screen 500 is displayed. The other project phase dates 523-525 are indefinite and may or may not be determined at a later time in the course of the project. A first project phase date 521 relates to the start date, 31/10/2017, in the example. The second project phase date 522 relates to the data collection date, 30/11/2017, in the example. The sixth and final project phase date 526 relates to the last deadline of the business case, 28/12/2017, in the example. The latter corresponds to the current phase of the project, where the project has already been defined, but a questionnaire still needs to be created and presented to one or more banks in order to select a bank. The dashboard screen 500, 700, and 800 therefore comprises a tab toolbar 510 comprising a first tab 511 As-is analysis with regard to all aspects of the as-is analysis, such as creating the questionnaire, and a second tab 512 Bank selection with regard to the selection of banks.
The first 511 and second 512 tab can be selected by the user. In dashboard screen 500 and 700 the first tab 511 is selected; in dashboard screen 800, the second tab 512 is selected. The dashboard screen 500 herein comprises a tab-related screen zone 530 comprising a selectable button for the
BE2017 / 5974 create a questionnaire. Upon selection, the web application displays a screen for creating a questionnaire 600, the details of which are given below. Once it has been created, the questionnaire can be sent and the web application displays the dashboard screen 700 of Figure 7. The dashboard screen 500 further includes the second tab 512 Bank selection. Selecting this tab displays a changed screen (not shown) with the tab-dependent screen zone including a selectable button (not shown) Creating an RFP; the selection starts the creation of an RFP.
Upon selection of the button for creating a questionnaire, the screen for creating a questionnaire 600 of Figure 6 is shown. The screen for creating a questionnaire 600 includes the header bar 320 which now further comprises a project-related screen zone 327 leading back to the project list screen 300, 400. The header bar 320 comprises a project-related screen zone 327, which refers to the title of the project and the company name for which a questionnaire has been created. The screen for creating a questionnaire 600 further comprises a template sidebar 610, in which various available templates 611-614 are shown, which can be changed via the settings-related item Template Company Questionnaire (see below), the last settings-related item being only available for the admin user. In this screen, the Template Plus 611 template with last edit date 24/11/2017 is currently selected, and the corresponding details are available for selection in the template detail screen zone 620. The template detail screen zone 620 includes a plurality of sections 621-624 and further sections (not shown) ). They each include a selection menu button 630 for displaying a list of questions and a check box 640 for indicating which of the sections included in the template are to be included in the questionnaire to be created. With a confirmation button 650, the selected sections can be transferred to the questionnaire that is created.
Figure 7 shows the dashboard screen 700 after a questionnaire has been created. In this phase, the answers to the questionnaire are entered by the business user via a suitable interface (not shown). These answers must now be analyzed by the moderator user. The dashboard screen 700 includes the tab-related screen zones 710, 720, 730. The tab-related screen zone 710 relates to the issue of the questionnaire and includes an indication of the publication date 711 of the questionnaire, as well as a selectable button 712 to display a view (not shown) on the structure of the questionnaire. The tab-related screen zone 720 relates to the completion of the questionnaire. The tab-related screen zone 720 comprises a
BE2017 / 5974 indication 721 of the number of questionnaires that have already been received by the web application, as well as the total number of questionnaires that are expected. The tab-related screen zone 720 further comprises a selectable button 722 for importing and exporting responses sorted by entity via a separate screen (not shown), as well as a selectable button 723 for importing and exporting responses sorted by category (e.g. , payments and collections, card collections, corporate credit cards, payment & reporting channels) under different entities via another separate screen (not shown). The said category corresponds to one of the sections 621-624 that can be selected in the template detail screen zone 620. The tab-related screen zone 730 relates to the reporting of the questionnaire responses, where the web application allows an output file, preferably a spreadsheet. output file. To this end, the tab-related screen zone 730 includes a selection menu 732 with options consolidated questionnaire 731 together with other options related to different reports that are available (not shown), as well as a selectable button 723 for generating the output file.
Figure 8 shows the dashboard screen 800 where the questionnaire has been completed and the answers analyzed, and the bank selection phase is ongoing. RFPs are issued and sent to the banks, and completion of the RFPs is awaited. Accordingly, the project phase timeline 520 now includes a date indication also for the fourth project phase date 524 with respect to the deadline of the business case, 11/12/2017 in the example, and the fifth project phase date 525 with regard to the deadline for selecting a bank.
The second tab 512 is selected for the dashboard screen 800. Accordingly, the dashboard screen 800 includes the tab-related screen zones 810, 820 and 830. The tab-related screen zone 810 relates to the RFPs that have been issued, including a plurality of screen zones 711, one for each RFP, indicating the RFP title, 06.11 RFP and RFP2 in the example , the end date for completion by banks, a selectable screen button for opening the RFP structure, and a selection menu for managing the RFP status. Here, the status, for published RFPs, is no longer editable, while RFPs can be set to layout mode (not shown) or ready for publication mode (not shown). The tab-related screen zone 820 includes an indication 821 of the number of responses to RFPs that have already been received by the bank's web application, as well as the total number of responses to RFPs that are expected. The tab-related screen zone 820 further comprises a selectable button 822 for opening the responses to the
BE2017 / 5974 RFPs via a separate screen (not shown). The tab-related screen zone 830 relates to the reporting of the responses of the RFPs, whereby the web application allows to calculate different types of reports. The type of report can be selected by means of selection menu 831, whereby the choice for eg price benchmark or price comparison is possible. Furthermore, the tab-related screen zone 830 includes a selectable button 832 for starting the generation of the report according to the selected type. Upon selection, a separate screen (not shown) allows you to enter parameters that are relevant to the type of report. In the case of the Price Benchmark, for example, this may relate to the annual turnover and the RFP to which the benchmark refers.
Figure 9 illustrates the screen for editing the project 900, then can only be viewed by moderator users. For these users, the editing screen for the project 900 is achieved by selecting the edit button 326 in the dashboard screen 500, 700, 800. The editing screen for the project 900 includes a sidebar for editing the project 930 with selection of different options that result in different data being displayed in the first 910 and second 920 option-related screen zone. In this example, the Project information option is selected, with corresponding contents of the option-related screen zones 910, 920, as shown. The first option-related screen zone 910 includes windows for entering data for the project name 911, the start date of the project 913, the project status 914, the preferred currency 915, the password of the project 916 and the period in which the data was collected 917, as well as a indication of contact persons 912 with regard to the moderator user. The dates of the project phases 521-526 can be entered via the data entry windows 921-926 in the second option-related screen zone 920. A selectable next button 940 leads to another option-related screen zone (not shown), ie the one that is associated with the Company Information option in the sidebar for editing a project 930.
Finally, selecting the system settings icon leads to a selection menu of setting related items that are displayed. Examples of institution-related items as they are shown to admin users are Country, Territory, Currencies, Banks, Standard Transaction, Local Transaction, Template - Company Questionnaire, Template - RFP In-Country Questionnaire, Template - RFP General Questionnaire, DWH Refresh, and Unsubscribe . Fewer institution-related items are shown to other users; business users and bank users, for example, are only shown Logout. Selecting Country results in a list of countries that are displayed (not
BE2017 / 5974); Certain general properties are displayed for each country. These properties can be edited via the web interface (not shown) and relate to, for example, the name of the country (eg Belgium), the code of the country (eg BEL), the currency (eg EUR), the area (eg Europe), the possibility (y / n) for a domestic cash pool, and the possibility for a cash pool outside the borders. Moreover, the services provided through the web application, i.e. the services monitored by the moderator user, are displayed in connection with the particular country only if they are active. The settings made in this screen result in changes for each of the projects handled by the web application, i.e., each project included in the project list screen. This also applies to various of the other institution-related items Area, Currency, Banks, Standard transaction and Local transaction. For example, by selecting Area, you can set different parameters at a level above countries, such as one or more continents (e.g., Europe, EMEA), where an upper area, e.g., EMEA for Europe), if applicable, can be specified, and or (y / n) services are active in the specific area. And by selecting Currencies, you can enter currencies and their names, activity (y / n), exchange rate and the date of the last exchange rate update.
The institution-related items Template - Company Questionnaire, Template - RFP Inland Questionnaire and Template - RFP General Questionnaire relate to the editing of templates. Once entered into the system, these templates can be accessed from other screens of the web application, such as the sidebar of the template 610 on Figure 6, showing various available templates 611-614 that can be changed via the setting related item Template - Company questionnaire.
Example 5: example of authentication
Figure 10 illustrates another aspect of the invention with regard to user authentication with respect to the computer system. Hereinafter, similar reference numbers indicate corresponding parts in Figure 10. In this example, user 1 relates to the business user; however, this can also relate to the moderator user or the bank user. The example can relate to the system according to claim 1, but it can also relate to another system. In the broadest sense, according to another aspect of the present invention that is not intended to limit its scope in any way, the invention provides a computer system that provides a server, a user interface, preferably a
BE2017 / 5974 includes a business user interface, and an IDAM server 4 different from said server; said user interface comprising a representation layer 2 configured for HTTPS-based interaction with a user-related device of the user 1, preferably business user; wherein said computer system comprises a web API 3 configured for interaction between said representation layer 2 and a processing part of said computer system; wherein said web API 3 is configured to validate a token generated by said IDAM server 4; wherein the use of said user interface relates to receiving and / or transmitting data between the user and the computer system and preferably relates to said receiving in step (a); and wherein said representation layer 2 is configured to perform the following steps, preferably, but not necessarily, belonging to step (a), which relate to authentication of said user 1 with respect to said computer system:
(a.i) receiving 11 credentials 5, preferably a user name and password, from said business user 1 via said HTTPS-based interaction with said user-related device;
(a.ii) requesting 12 from said token 6 from said IDAM server 4 based on said credentials 5;
(a.iii) receiving 13 of said token 6 from said IDAM server and storing said token 5;
(a.iv) providing 14 to said user 1 access to the computer system;
(a.v) receiving a portion of said required data from said business user via said HTTPS-based interaction;
(a.vi) sending 16 a message comprising said portion of said required data received in the step (av) and said token 6 stored in the step (a.iii) to said web API 3 ;
(a.vii) after optional validation 170 of said token 6, receiving 17 a response from said web API 3 to said portion of said required data;
BE2017 / 5974 (a.viii) giving said user 1 the said answer to said part of said required data.
Similarly, the invention provides the related method according to steps (ai) - (a.viii), wherein the means necessary for performing the method, ie the server, the IDAM server, the web API, and the business user interface, comprising the representation layer provided in a previous step. A possible context of this example is the situation of an unauthenticated user 1 (who is not yet logged in) navigating to the web application, where the application forwards the request to the IDAM server 4 to start the authentication process and a display the login screen, where the user 1 enters credentials 5 such as a login and password. The IDAM server 4 then validates the credentials 5 and forwards the request to the web application with a generated valid token 6 as a parameter on the returned URL.
From that point the user 1 is considered authenticated, so he can communicate with the application and perform any action and request to the web APIs 3. Since all requests to the server must have a valid token 6 on its headers, the web APIs 3, preferably REST web APIs, can perform the validation of the token 6 and verify that each request is from an authentic source.
If the signatures, preferably the JSON web signatures regarding the use of a JSON web token, do not match, it means that the received token 6, preferably a JSON web token, is invalid, which may be an indicator of a possible attack on the application. By checking the token 6, the application adds a layer of trust.
The aforementioned web API preferably relates to a REST API. Said representation layer preferably relates to HTML 5, more preferably to HTML 5 AngularJS. Web pages are preferably encrypted by SSL. The said token preferably relates to a JSON web token. Here step (a.i) relates to the launch of the application. Step (a.ii) relates to requesting a token 6 using a mobile certificate. Step (a.iii) relates to the return of the token 6. Step (a.iv) relates to the confirmation of the authentication with the user 1 and making the application available to the user 1. Step (av) refers to an action performed by the user 1. Step (a.vii) refers to requesting a source with a token 6. Step (a.vii) refers to the optional validation of the token 6 and the return the requested source. Step (a.viii) relates to display
BE2017 / 5974 of information regarding the requested source about the said representation layer to the user 1.

权利要求:
Claims (10)
[1]
A computer system for cash management, wherein the computer system comprises
- a server, the server comprising a processor, a tactile non-volatile memory, program code present on said memory for giving instructions to said processor;
- a computer-readable medium, wherein the computer-readable medium comprises a database, said database comprising historical data on bank transactions;
wherein said computer system is configured to perform a method for generating an action proposal design, said method comprising the following steps:
(a) receiving required data from a business user by said server, said requirement data comprising a plurality of capacity requirements for bank transactions with regard to cash management and cash;
(b) processing said required data by said server to generate an actual / desired analysis design that is available to a moderator user, said processing being based at least in part on said historical bank transaction data;
(c) receiving a change of said requirement data from said moderator user and / or said business user, yielding changed requirement data;
(d) processing said modified requirement data by said server for generating request data comprising an RFP (Request For Proposal) and a recipient list, said processing being based at least in part on said historical bank transaction data;
(e) upon confirmation by at least said moderator user, sending said RFP to a plurality of bank users named in said recipient list;
BE2017 / 5974 (f) receiving response data from said server from one or more bank users belonging to said plurality of bank users, said response data comprising a capacity selection for bank transactions and a plurality of bank transaction prices with respect to said plurality of capacity requirements on bank transactions;
(g) processing said response data by said server to generate said promotional proposal design available to said moderator user, said promotional proposal design comprising one or more of said plurality of bank transaction prices with respect to said plurality of capacity requirements on bank transactions;
characterized in that said receiving in step (f) comprises at least partially automated updating of said historical bank transaction data based on said response data, and said processing in step (g) comprises comparing a bank transaction price that belongs up to said plurality of bank transaction prices with an amount calculated on the basis of or available in said historical bank transaction data.
[2]
A computer system according to the preceding claim 1, characterized in that said computer system further comprises a corporate user interface and an IDAM server (4) that is different from said server; that said corporate user interface includes a representation layer (2) configured for HTTPS-based interaction with a user-related device of the corporate user (1); said computer system includes a web API (3) configured for interaction between said representation layer (2) and a processing part of said computer system; said web API (3) is configured to validate a token (6) generated by said IDAM server (4); that said receiving in step (a) relates to the use of said corporate user interface; and that said representation layer (2) is configured to perform the following sub-steps that belong to step (a) and that relate to authentication of said user (1) with respect to said computer system:
BE2017 / 5974 (a.i) receiving (11) credentials (5), preferably a user name and password, from said business user (1) via said HTTPS-based interaction with said user-related device;
(a.ii) requesting (12) said token (6) from said IDAM server (4) based on said credentials (5);
(a.iii) receiving (13) said token (6) from said IDAM server (4) and storing said token (6);
(a.iv) providing (14) to said user (1) access to the computer system;
(a.v) receiving (15) a portion of said required data from said business user (1) via said HTTPS-based interaction;
(a.vi) sending (16) a message comprising said portion of said required data received in the step (av) and said token (6) stored in the step (a.iii) to the said web API (3);
(a.vii) after optional validation (170) of said token (6), receiving (17) a response from said web API (3) to said portion of said required data;
(a.viii) giving said user (1) said answer to said part of said required data.
[3]
A computer system according to the preceding claim 2, characterized in that said web API relates to a REST API; that said representation layer relates to HTML 5; and that said token relates to a JSON web token.
[4]
A computer system according to claims 1 to 3, characterized in that said computer system comprises a business user interface suitable for display to the business user; and that said receiving in step (a) relates to the use of said business user interface, said business user interface comprising a questionnaire suitable for successive completion by said business user, said questionnaire comprising a plurality of
BE2017 / 5974 comprises questions relating to cash management and cash, wherein said questionnaire comprises at least one interdependence between a first and a second question that belongs to said plurality of questions.
[5]
5 benchmarking bank user interface, wherein said benchmarking bank user interface comprises a questionnaire suitable for successive completion by said benchmarking bank user interface, said questionnaire comprising a plurality of questions regarding benchmarking.
Computer system according to the preceding claim 4, characterized in that at least one of said plurality of questions relates to any or any combination of the following: an estimated annual turnover, estimated annual total bank costs, a detailed unit cost, a country-specific overview of transaction types.
[6]
A computer system according to any one of the preceding claims 4 to 5, characterized in that, with respect to said successive completion of said questionnaire by said business user, a sum of two or more quantities given by said business user in response to said said plurality of questions is compared with an estimate also given by said business user in response to said plurality of questions, said estimate referring to said sum of two or more quantities.
[7]
A computer system according to the preceding claim 6, characterized in that said business user interface is configured to generate a warning for said business user when said sum of two or more quantities falls outside a range defined by said estimate and a predefined tolerance level.
[8]
A computer system according to any one of the preceding claims 4 to 7, characterized in that said business user interface comprises a progress bar indicating a progress of said business user in completing said questionnaire.
[9]
A computer system according to any one of the preceding claims 4 to 8, characterized in that said computer system comprises means for assisting the moderator user in creating said questionnaire.
A computer system according to any one of the preceding claims 1 to 9, characterized in that said computer system comprises a bank user interface that is suitable for display to the business user; and that it
BE2017 / 5974 said received in step (d) relates to the use of said bank user interface, said bank user interface comprising a display of a plurality of requests based at least in part on said RFP, said display of said plurality of requests requests is suitable for successive completion by said bank user.
A computer system according to any one of the preceding claims 1 to 10, characterized in that said computer system comprises a user account comprising contact details for at least one of the bank user, the moderator user and the business user; and that said computer system is further configured to send a notification to said bank user and / or said moderator user and / or said business user via said contact details, said notification being triggered by a calendar item and / or deadline with respect to said method for generating said promotional proposal design.
A computer system according to any one of the preceding claims 1 to 11, characterized in that said promotional proposal design comprises more than one alternative to the promotional proposal.
A computer system according to any one of the preceding claims 1 to 12, characterized in that said computer system is further configured to perform a method for generating a bank benchmark report design, said method comprising the following steps:
(i) retrieving benchmarking information relating to a benchmarking bank user by said server;
(ii) processing said benchmarking information to generate said bank benchmarking report design, said processing being based at least in part on said historical bank transaction data;
wherein said benchmarking information is retrieved in step (i) by any or only combination of: querying said benchmarking bank user; requesting the aforementioned historical data on bank transactions.
BE2017 / 5974
A computer system according to claim 13, characterized in that said computer system comprises a benchmarking bank user interface suitable for display to the benchmarking bank user; and that said retrieval in step (i) relates to the use of said
[10]
15. Use of a cash management computer system according to any of the preceding claims 13 and 14 for generating a benchmarking bank report design.

类似技术:

---

公开号 | 公开日 | 专利标题

---

Davenport2000|The future of enterprise system-enabled organizations

---

Lohman et al.2004|Designing a performance measurement system: A case study

---

US7168045B2|2007-01-23|Modeling business objects

---

Zolkiewski et al.2002|Do relationship portfolios and networks provide the key to successful relationship management?

---

US20070282673A1|2007-12-06|Method and system for implementing portal

---

Grabski et al.2009|Management accounting in enterprise resource planning systems

---

US20110145284A1|2011-06-16|Presenting skills distribution data for a business enterprise

---

US7519539B1|2009-04-14|Assisted profiling of skills in an enterprise management system

---

US20090248589A1|2009-10-01|Systems and Methods for Real-time, Dynamic Multi-Dimensional Constraint Analysis of Portfolios of Financial Instruments

---

US20110184745A1|2011-07-28|Business enablement system

---

Verma2009|Business process management: profiting from process

---

Dresner2007|The performance management revolution: Business results through insight and action

---

US20020198807A1|2002-12-26|Product brokerage transaction processing system, and product brokerage transaction processing method and program

---

GB2424290A|2006-09-20|Managing printing devices at distributed sites

---

CA2738705C|2017-01-10|Computer implemented system for self-managed incentive program

---

BE1025733B1|2019-06-24|IMPROVED CASH MANAGEMENT SERVICE PLATFORM

---

Delporte-Vermeiren et al.2004|In Search of Margin for Business Networks:: The European Patent Office

---

US20040215547A1|2004-10-28|Automated liability management and optimization system

---

Mättö2012|Implementation of quality cost management tool in dyadic purchaser-provider relationship context

---

Brem2015|Keeping track of the performance of the Purchase-to-pay process of Philips Lighting

---

Elbaidi2021|The supplier selection process in online sourcing: case company: SAS MNYTrading

---

Chilton2013|The business expansion decision making process for multinational enterprises investing in Canada

---

NAVEEN et al.2019|CUSTOMER CHURN ANALYSIS

---

Goundar et al.2021|EXPLORING THE COMPETITIVE ADVANTAGE OF ERP IN TELECOMMUNICATIONS

---

Lindenbauer et al.2018|Master of Science Global Business

同族专利:

---

公开号 | 公开日

---

BE1025733A1|2019-06-21|

---

WO2018115348A1|2018-06-28|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

US20070136794A1|2005-12-08|2007-06-14|Microsoft Corporation|Request authentication token|

---

US8190504B1|2010-12-23|2012-05-29|Accenture Global Services Limited|Corporate payments, liquidity and cash management optimization service platform|

---

法律状态:
2019-07-10| FG| Patent granted|Effective date: 20190624 |

优先权:

---

申请号 | 申请日 | 专利标题

---

EP16206636.9|2016-12-23|

---

EP16206636|2016-12-23|

---